• Article Type: General
• Product: Aleph
• Product Version: 18.01

Description:
I ran manage-36 to match a bib that I knew was there in TEST abc01. There was no match listed in the second output file, it was listed in the first output file as a new record.

The 035 from the existing record (004904055) in TEST:

0359 $$a(SFX)HA110978966558810

The 035 from the new record (aleph sequential format) run in manage-36:

000000001 0359 L $$a(SFX)HA110978966558810

The parameters used in manage-36:
...
0359A (match section)

The tab_match entry for CNO2:

0359A match_doc_uid I-CNO2

The tab11_ind entry:

0359 CNO2 a

The tab00.eng entry:

H CNO2 IND 27 00 00 Innopac System Numbe

The tab_filing entry:

27 del_subfield
27 to_lower
27 compress .
27 compress_blank

In other words we want an alphanumeric index of the 0359 $$a.

We thought that this might have to do with the parentheses in the 0359 field, but testing with parentheses removed from the 0359 in both the existing record and in the input record still failed to match.

Resolution:
This field in the input record:

000000001 0359 L $$aSFXHA110978966558810

*should* match this abc01 CNO2 z11:

03 ind_code .......CNO2
03 filing_text ....sfxha110978966558810

My diagnostics show that it does not because it has a trailing ASCII line feed character "^M":

DOCX-TEXT= $$aSFXHA110978966558810^M

This character does not show up in "vi" for some reason -- but clearly it is there....

My experience has been that this character is present when you have ftp-ed an ASCII file in BINARY mode, rather than ASCII.

There are two ways to get rid of these control characters:

1. re-ftp the file, typing "ASCII" on the ftp command line prior to doing the ftp.

2. Enter this command at the unix prompt on your server:

dos2unix xxxxxxxxx <where "xxxxxxxxx" is the name of the file> (on LINUX systems)
dos2unix -ascii xxxxxxxxx xxxxxxxxx <where "xxxxxxxxx" is the name of the file> (on SUN systems)

• Article last edited: 10/8/2013